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I. REAL PARTY IN INTEREST 



The real party in interest is the assignee or record, Quest Software, Inc. 



II. RELATED APPEALS AND INTERFERENCES 



The Appellants know of no other appeals or interferences which will directly affect, 
be directly affected by, or have a bearing on the Board's decision in this Appeal. 



Claims 1-19 and 21-34, as listed the Claim Appendix, remain pending and are the 
subject of this Appeal. 

On June 30, 2004, when responding to an Office Action mailed on March 9, 2004, 
Applicant canceled Claim 20. 

On August 29, 2005, the Examiner finally rejected pending Claims 1-19 and 21-34. 



The present application includes five independent claims. Each independent claim is 
paraphrased below, with citations to corresponding portions of the specification and 
drawings as required by 37 C.F.R. § 41.37(c)(l)(v). 

These citations are provided in order to illustrate specific examples and embodiments 
of the recited claim language, and not to limit or interpret the claims. Furthermore, a 
citation to a specific paragraph or appendix in the following claim summaries should be 
treated as a citation to all lines of that paragraph or appendix. 

Claims 1,2, 17, 26, and 34 are independent claims, however, before discussing each 
of the claims individually, Applicant has provided a brief overview. 



III. STATUS OF CLAIMS 



IV. STATUS OF AMENDMENTS 



No amendments were made in response to the Final Office Action. 



V. SUMMARY OF CLAIMED SUBJECT MATTER 
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Brief Overview 

With reference to Figure 1, the claims are directed to systems and methods for 
synchronizing two systems - a source system 105 and a target system 110. To ensure 
synchronization, a replication system 115 captures changes made to the source system 
105 and forwards these changes to the target system 110. 
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FIG. 1 

The replication system 115 stores the changes made to the source system 105 in a 
poster queue 135 until the replication system 115 can apply the changes to the target 
system 110. For example, during periods where the target system 110 is temporarily 
unavailable due to maintenance or inaccessiblity, the changes remain in the poster queue 
135 until the target system 110 becomes available. Once the target system 110 becomes 
available, the replication system 115 applies the changes pending in the poster queue 135 
to the target system 110. 

Unsynchronizing events such as a crash of the target system 110, however, can cause 
problems when replicating data from the source system 105 to the target system 110. In 
such instances, duplicative or stale transactions can exist in the poster queue 135 after 
recovery of the target system 110. 



-4- 



Docket No. 
Application No. 
Filing Date 



QSOFT.010A 
09/782,586 
February 12, 2001 



Appeal Brief 
Customer No.: 20,995 



Thus, the pending claims are directed to a replication system 115 that deletes 
stale transactions after recovery of the target system 110. 

For example, assume that the source system 105 and the target system 110 represent 
databases of bank accounts. In addition, assume that after the target system 110 crashes, 
the source system 105 remains available and continues to process transactions. In this 
example, a user deposits $100 into his account. This $100 deposit transaction will be 
applied to the person's account in the source system 105 as the source system 105 remains 
available. 

In addition, replication system 115 stores the $100 deposit transaction in the poster 
queue 135 so that that $100 deposit can be applied to the target system 110 once the target 
system 110 becomes available. 

In this example, the crash of the target system 110 requires recovery of the target 
system 110. One way of recovering the target system 1 10 is to physically transfer a copy 
of the source system 105 on a recording medium to the location of the target system 110. 
This copy of the source system 105 is then used to restart the target system 110. 

In this example, the copy of the source system 105 is made after the completion of the 
$100 deposit. Consequently, the user account in the recovered target system 110 will 
show that $100 has been deposited into the account. 

Focusing now on the replication system 115, in this example, the $100 deposit 
transaction is still pending in the poster queue 135 as the target system 110 has been 
unavailable since it crashed. Once the target system 110 becomes available, the 
replication system 115 will want to apply the $100 deposit transaction pending in the 
poster queue 135 to the target system 110 such that the user's account will be updated 
twice. As a result, the user account in the recovered target system 110 will indicate that 
an additional $100 deposit has occurred resulting in an overall increase of $200. 

While the user may enjoy this double deposit, the bank will not. Also, the amount in 
the user account of the target system 110 ($200) will differ from the amount of the user 
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account. in the source system 105 ($100). That is, the replication system 115 that seeks to 
keep the two systems synchronized will cause an error. 

This error occurs because the modified data in the source system 105 was copied to 
the target system 110 while information about the modified data remained in the reconcile 
poster 135. See for example, the patent application at page 10, lines 20-3 1 . 

The pending claims address this problem by claiming a replication system 115 that 



deletes duplicative or "stale" transactions from the poster queue 135 after recovery of the 
target system 110. See for example, page 11, lines 1- 8. 
Independent Claim 1 

Claim 1 is directed to a device for performing replication between a source system 
and a target system. With reference to Figure 1, the device is a replication environment 
100 that comprises a source system 105, a replication system 115 and a target system 110. 
The replication system 115 captures changes made to source system 105 and forwards 
those changes to the target system 110, thereby synchronizes the data of the source system 
105 and the data of the target system 110. See, e.g., page 5, line 27 to page 6, line 6. The 
device comprises: 

• a source system (see, e.g. 105 in Figure 1) having data files 120, and log files 
125 storing replication transactions corresponding to changes made to the data 
files (see, e.g., page 7, lines 3-12); 

• a recovered target system 110 wherein the recovered target system 110 
comprises a rolled back copy of the data files in the source system 105 and 
wherein the rolled back copy of the data files comprises data that is associated 
with at least one replication transaction stored in the log files 125 (see, e.g., 
page 13, lines 29 to page 14, line 8); 

• a replication system 1 1 5 performing replication of at least portions of the data 
files of the source system 105 to the recovered target system 1 10 by reading the 
log files and posting the changes from the log files 125 to the recovered target 
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system 110, the replication system 115 comprising (see, e.g., page 5, line 30 to 
page 8, line 6): 

• transaction-level poster queues 135, each poster queue 135 storing 
statements corresponding to a particular replication transaction from the 
source system 105 (see, e.g., page 8, lines 26-29), and 

• a reconcile process 143 which purges replication transactions from the 
poster queues 135 when the replication transactions have already been 
applied to the recovered target system 110 (see, e.g., page 10, line 20 to 
page 11, line 8); and 

• wherein the replication system 115 performs the replication transactions by 
rolling forward at least some of the information rolled back during the recovery 
of the recovered target system 1 10 such that the purged replication transactions 
in the poster queues 135 are not applied while rolling forward (see, e.g., page 
14, lines 5-9, page 15, lines 8-11, and page 17, line 27 to page 18, line 16) such 
that the source database 120 remains available during recovery of the recovered 
target database 127 (see e.g., page 12, lines 20-25). 

Independent Claim 2 

Claim 2 is directed to a replication system 115 that replicates at least portions of the 
data contained in a source database 120 to a target database 127. The replication system 
115 (see, e.g., page 5, line 30 to page 8, line 6) comprises: 

• poster queues 135 which store information corresponding to changes made to 
at least portions of a source system 105 (see, e.g., page 8, lines 26-29); 

• at least one poster process 140 which reads the information stored in the poster 
queues 135 and generates commands interpretable by a target system 110 and 
designed to change the target system 110 to reflect the changes made to the at 
least portions of the source system 105 (see, e.g., page 9, lines 17-23); 
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• instantiation or recovery process 200 of the target system 110 that rolls back 
information previously applied to the target system 110 such that the target 
system 110 comprises at least a copy of some of the information stored in the 
poster queues 135 (see, e.g., page 13, lines 4-1 1 and page 14, lines 2-8); and 

• a reconcile process 143 which purges stale information stored in the poster 
queues 135, the stale information corresponding to changes made to the target 
system 110 during the instantiation or recovery thereof (see, e.g., page 10, line 
20 to page 11, line 8); and wherein the poster queues 135 roll forward at least 
some of the information rolled back during the recovery of the recovered target 
system 110 such that the purged stale information is not applied while rolling 
forward (see, e.g., page 14, lines 5-9, page 15, lines 8-11, and page 17, line 27 
to page 18, line 16) and wherein the source system 105 remains available 
during instantiation or recovery of the target database 127 (see e.g., page 12, 
lines 20-25). 

Independent Claim 17 

Claim 17 is directed to a method of recovering or instantiating a target database 127 
during replication from a source database 120 to the target database 127, (see, e.g., page 
5, line 30 to page 8, line 6) the method comprising: 

• creating a target database 127 that has a copy of data from a source database 
120 (see, e.g., page 8, lines 18-20); 

• logging replication transactions in a replication system 115 wherein the 
replication transactions are associated with changes made to the source 
database 120 (see, e.g., page 7, lines 8-10); 

• applying the replication transactions to the target database 127 to maintain in 
the target database 127 a copy of the source database 120 (see, e.g., page 8, 
lines 18-20); 
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• identifying an unsynchronizing event associated with the target database 127 
(see, e.g., page 10, lines 25-28); 

• recovering the target database 127 by rolling back information previously 
applied to the target database 127 such that the recovered target database 127 
contains a copy of at least some of the changes represented by the replication 
transactions contained in the replication system 115 (see, e.g., page 13, lines 29 
to page 14, line 8); 

• reconciling the recovered target database 127 with the replication transactions 
contained in the replication system 115, thereby purging stale replication 
transactions from the replication system 115 (see, e.g., page 10, line 28 to page 
11, line 8); and 

• restarting replication by rolling forward at least some of the information rolled 
back during the recovery of the target database 127 such that the purged stale 
replication transactions are not applied during replication (see, e.g., page 14, 
lines 5-9, page 15, lines 8-11, and page 17, line 27 to page 18, line 16) and 
wherein the source database remains available during recovering, reconciling 
and restarting (see e.g., page 12, lines 20-25). 

Independent Claim 26 

Claim 26 is directed to a method of reconciling transactional information stored in a 
replication system 115 with a recovered database 127 (see, e.g., page 10, line 28 to page 
11, line 8), the method comprising: 

• parsing a log file 145 of a recovered database 127 to determine a placement 
indicator of a recovery flag (see, e.g., page 14, lines 9-10); 

• rolling back information previously applied to a recovered database 127, 
wherein the recovered database 127 comprises at least some data that is also 
represented by transaction data that exists in the log file 145 (see, e.g., page 13, 
lines 4-1 1 and page 14, lines 2-8); 
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• reading the transaction data corresponding to changes made to a source 
database 120 to determine placement indicators of completed transactions (see, 
e.g., page 15, lines 14-25); 

• purging the transactional data when the placement indicator corresponding to 
the completed transaction occurred before the placement indicator of the 
recovery flag (see, e.g., page 16, lines 1-13); and 

• replicating the transactional data to the recovered database 127 by rolling 
forward at least some of the information rolled back during the recovery of the 
recovered database 127 such that the purged transaction data are not applied 
during replication replication (see, e.g., page 14, lines 5-9, page 15, lines 8-11, 
and page 17, line 27 to page 18, line 16) such that the source database remains 
available while replicating the transactional data to the recovered database (see 
e.g., page 12, lines 20-25). 

Independent Claim 34 

Claim 34 is directed to a device comprising: 

• a source system 105 having a source database management system (SDBMS) 
which governs the storage of data within the source system 105 and creates a 
log file 125 tracking changes made to the source system 105 (see, e.g., page 7, 
lines 3 to 18); 

• a target system 110 having a target database management system (TDBMS) 
which governs the storage of data within the target system 110 and creates a 
log file 145 tracking the changes made to the target system 110 wherein the 
target database management system is configured to recover the target system 
110 by rolling back portions of previously applied information (see, e.g., page 
9, lines 20-23 and page 13, line 29 to page 14, line 8); and 



• a replication system 115 having queues 135 and communicating with the log 
file 145 of the TDBMS and the log file 125 of the SDBMS, thereby purging 
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from the queues 135 the replication transactions applied after the beginning, 
but before the completion, of the recovery of the target system 110 (see, e.g., 
page 10, line 28 to page 11, line 8), wherein the replication transactions 
correspond to the changes made to the source system 105 wherein the 
replication system 115 is configured to roll forward at least some of the 
information rolled back during the recovery of the target system 110 such that 
the purged replication transactions are not applied during replication (see, e.g., 
page 14, lines 5-9, page 15, lines 8-11, and page 17, line 27 to page 18, line 16) 
such that the source system 105 remains available during recovery of the target 
database 127 (see e.g., page 12, lines 20-25). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The following rejections are to be reviewed on appeal: 

1. The rejection of Claims 17-19 under 35 U.S.C. § 101 as being directed to non- 
statutory subject matter. 

2. The rejection of Claims 1-19 and 21-34 under 35 U.S.C. § 103 as being 
unpatentable over U.S. Patent No. 5,640,561 to Satoh et al. ("the Satoh patent") in view 
of a publication regarding Microsoft's Exchange by Pagano et al. (the "Pagano 
reference"). 



A. Rejection of Claims 17-19 under 35 U.S.C. § 101 

The Examiner rejected Claims 17-19 under 35 U.S.C. § 101 as being directed to non- 
statutory subject matter. In the rejection, the Examiner states that Clams 17-19 and 21-33 
are "not statutory because they merely recite a number of computing steps without 
producing any tangible result and/or being limited to a practical application within the 
technical arts." 



VII. ARGUMENT 
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Independent Claim 17 



Applicant respectfully asserts that Claim 17 is patentable as Claim 17 recites useful, 
concrete and tangible results. 

First, it does not appear that the Examiner has taken the position that Claim 17 is 
directed to a law of nature, physical phenomena or an abstract idea as Claim 17 is clearly 
directed to a process of purging stale replication transactions from a replication system. 

Second, Claim 17 recites tangible results in that it purges stale replication 
transactions from the replication system such that the purged stale replication transactions 
are not applied during replication. Thus, Claim 17 clearly recites a useful, concrete, and 
tangible result. 

Third, it appears that the Examiner rejects Claim 17 as not being directed to a 
practical application within the technical arts. This, however, is not a separate ground for 
rejection. In Ex parte Lundgren , Appeal No. 2003-2088, Application 08/093,516 
(Precedential BPAI Opinion September 2005), the Board of Patent Appeals and 
Interferences has specifically stated that there is not a separate technical arts test. 
Lundgren at 9. 

Accordingly, Applicant's should not be required to amend Claim 17 to incorporate 
the "computer-implemented" limitation as requested by the Examiner. 
Dependent Claims 18 and 19 

Because Claims 18 and 19 depend from Claim 1, the rejection of Claims 18 and 19 
are improper for the reasons set forth above for Claim 1 and because of the additional 
limitations recited therein. However, for the purposes of Applicant's appeal of the 
rejection under 35 U.S.C. § 101, Claims 18 and 19 stand or fall with Claim 1. 
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B. Rejection of Claims 1-25 and 34 under 35 U.S.C. § 103 

The Examiner rejected Claims 1-19 and 21-34 under 35 U.S.C. §103(a) as being 
unpatentable over the Satoh patent in view of the Pagano reference. 

As an initial matter, Applicant desires to point out that the Satoh patent maintains a 
replica of a source database. The Satoh patent, however, does not describe how to 
reconcile the source and replica database if the replica goes off-line and then needs to be 
recovered. 

While the Pagano reference discusses how to recover a database in the event of a 
system crash or other disaster, the Pagano reference does not provide any teaching 
regarding applying replication transactions from a source database to a recovered 
database. 

Thus, even if the references could be combined, which they cannot, the combination 
does not teach the general concept of a replication system that reconciles a source system 
with a recovered target system. 

Furthermore, even if the references could be combined, which they cannot, the 
combination does not teach a replication system that purges replication transactions 
before they are applied to a recovered target system. 

Independent Claim 1 

Claim 1 is directed to a replication system that reads the log files 125 of a source 
system 105 to identify transactions that alter the source system 105. The replication 
system 115 then stores these transactions in poster queues 135 (hereinafter the 
transactions stored in the poster queues 135 will be referred to as replication 
transactions). The replication system 115 applies the replication transactions to a 
recovered target system 110. 

When the target system 110 fails, the source system 105 remains available. Thus, 
when a user deposits $100 into his account, the $100 deposit transaction is applied to the 
user account in the source system 105. 
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Also, because this transaction has modified the source system 105, the target system 
110 needs to be modified in order to maintain consistency. Because the failed target 
system 110 is currently unavailable, the replication system 115 stores this $100 deposit 
transaction as a replication transaction in the poster queues 135. In this example, this 
replication transaction remains pending in the replication system 115 while the target 
system 1 10 is unavailable. 

Focusing now on the recovery of the target system 1 10, in order to recover the target 
system 110, a copy of the source system 105 is used. It is helpful to know that in the 
source system 105 there are at least two types of transactions - 1) completed transactions 
and 2) partially completed transactions. At any point in time, the source system 105 will 
likely have completed some transactions and partially completed other transactions. 

Thus, the copied source system 105 used to recover the target system 110 typically 
has both completed and partially completed transactions. During the recovery process, 
the partially completed transactions are removed or "rolled-back" such that the partially 
completed transactions are undone. 

The modifications associated with completed transactions, however, remain in the 
recovered target system 110. In this example, the $100 deposit transaction was completed 
and thus the modified user account in the recovered target system 110 indicates that an 
additional $100 exists in the user account. 

Focusing now on the replication system 115, the associated $100 deposit replication 
transaction is still pending in the poster queues 135. If this replication transaction is then 
applied to the recovered target system 110 an error will occur as the recovered target 
system 110 has the modified user account therein. 

In other words, the replication transaction associated with the $100 deposit is no 
longer needed as the recovered target system 110 already shows that $100 has been 
deposited into the user account. Thus, the $100 deposit replication transaction is referred 
to as a "stale" replication transaction and needs to be purged from the poster queues 135. 
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None Of The Cited References Have A Recovered Target System That Contains 
Data Associated With A Pending Replication Transaction 

Completed transactions alter the source system 105 and thus, the reconcile system 
1 1 5 stores a copy of these transactions as replication transactions in the poster queues 



After the failure of the target system 110, one way of recovering the target system 
110 is to transfer a copy of the source system 105 to the target system 110. The copied 
source system 105, however, typically has transactions that occurred after the crash of the 
target system 1 10. 

Also, it is helpful to know that at any point in time, some of the transactions applied 
to the source system 105 will have been completed while other transactions may have 
only been partially completed. During the recovery process, the partially completed 
transactions contained in the copy of the source system 105 are removed or "rolled-back" 
such that the partially completed transactions are undone. Thus, the recovered target 
system 1 10 is a rolled back copy of the source system 105. 

In particular Claim 1 states: 

"a recovered target system wherein the recovered target system comprises 

a rolled back copy of the data files in the source system and wherein the rolled 

back copy of the data files comprises data that is associated with at least one 

replication transaction stored in the log files', and" 

The rolled-back copy of the source system 105, however, has at least one transaction 
that was completed. Hence there is a replication transaction pending in the poster queues 
135 that is associated with the completed transaction. 

For example, data about the $100 deposit transaction is in both the recovered target 
system 1 10 and in the log files 125. Thus, the recovered target system 1 10 has data files 
that comprise data (the $100 in the user account) that is associated with a transaction in 
the log files 125 (the $100 deposit replication transaction). 



135. 
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The Applicant respectfully asserts that the Examiner incorrectly states on page 5 of 
the Final Office Action that the Satoh patent teaches this concept in Figures 1 and 3 and 
at Column 3, lines 20-50. 

Figure 1 of the Satoh patent appears to show an active computer system and a backup 
computer system. Figure 2 shows changes made to one database are copied to shadow 
databases. 

Column 3, lines 20-50 of the Satoh patent appear to describe the general concept of 
copying transactions applied to an active database to a backup system. These transactions 
are transferred as redo records. When a transaction becomes a committed transaction, the 
transaction in the redo record is identified and applied to the backup database. 

The Satoh patent, however, does not describe the claimed recovered target database. 
To do so, the Satoh patent would need to teach the recovery of a backup system, which it 
does not. The Satoh patent would also need to teach that the recovered backup system 
rolls back partially completed transactions, which it does not. In addition, the Satoh 
patent would need to teach a recovered backup system wherein the data files comprise 
data that is associated with a transaction in the redo log, which it does not. 

Thus, the Examiner is incorrect in asserting that the Satoh patent teaches the claimed 

recovered target system as set forth in Claim 1 . Furthermore, none of the cited references 

describe the concept of recovering a target system. None of the cited references describe 

the concept of rolling back the recovered target system. Still further, none of the cited 

references describe a recovered target system having data that is associated with a 

reconcile transaction stored in a log file. 

None of the Cited References Teach The Purging Of Stale Reconcile 
Transactions 

Claim 1 is directed to a replication process that purges stale replication transactions 
when the transactions have already been applied to the recovered target system: 
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"a reconcile process which purges replication transactions from the 
poster queues when the replication transactions have already been applied to 
the recovered target system ; and" 

The Examiner concedes that the Satoh patent does not disclose a reconcile process 
that purges replication transactions from the poster queues. To teach this concept, the 
Examiner relies on the Pagano reference. 

While the Pagano reference appears to discuss how to recover a database in the event 
of a system crash or other disaster, the Pagano reference only describes a single database 
system. That is, in the Pagano reference there is not a source and a target system. 

On page 4 of the Final Office Action the Examiner states: 

"Pagano teaches purging replication transactions from the poster queues 
when the replication transactions have already been applied to the recovered 
target system; and wherein the replication system; and wherein the replication 
system performs the replication transactions by rolling forward at least some 
of the information rolled back during the recovery of the recovered target 
system such that the purged replication transactions in the poster queues are 
not applied while rolling forward such that the source database remains 
available during recovery of the recovered target database (Pagano, page 3, 



Applicant, however, cannot find any reference in Pagano to replication transactions 
that have already been applied to a recovered target system. Pagano does not have source 
and target databases. Thus, Pagano does not have a replication system that maintains 
consistency between source and target systems. Furthermore, Pagano makes no mention 
of replication transactions whatsoever. Thus, Applicants respectfully submits that the 
Examiner has misread the Pagano reference. 

Rather, it appears that the disclosure in pages 3 and 8-11 of the Pagano reference 

describes the rolling back and rolling forward of transactions to recover a database to a 

particular point. For example the on page 11, the Pagano reference states: 

"When a Microsoft Exchange Server information store or directory is started 
after abnormal server shutdown - the transaction log file is scanned to see if 



page 8-11). 
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there were any incomplete transactions. If there were, these transactions are 
"rolled back" automatically to the state before they took place. This automatic 
recovery operation is relatively quick, since only the most recent transactions 
in the log have to be checked." 

These rolled-back transactions, however, are not purged. Rather they are applied to 

the recovered database. Page 21 of the Pagano reference states: 

"When the Information Store starts it will roll forward through all the existing 
database logs and place the data into the restored Information Store. This will 
bring the Information Store back to the point of the crash. If successful there 
will be no loss of data at all." 

Applicant is unable to find any discussion in the Pagano reference that teaches that 
the recovered database contains data such that transactions need to be purged from the 
logs. 

Thus, even if the Pagano reference could be combined with the Satoh patent, which it 
cannot, the combination would not teach the purging of replication transactions from the 
poster queues to prevent replication transactions from being applied to the recovered 
target system. 

None of the Cited References Teach a Source System That Remains Available 
During Recovery 

In Claim 1 the source system remains available during recovery of the target system: 

"wherein the replication system performs the replication transactions by 
rolling forward at least some of the information rolled back during the 
recovery of the recovered target system such that the purged replication 
transactions in the poster queues are not applied while rolling forward such 
that the source database remains available during recovery of the recovered 
target database'' 

When the database in the Pagano reference fails, the database becomes unavailable 
until the database is recovered. Because the Pagano only describes one database, the 
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Pagano reference does not teach the concept of a source database that remains available 
during recovery of the a recovered target database. 

While the Satoh patent describes the synchronization of an active database with a 
backup database, the Satoh patent does not mention the possibility of the failure of the 
backup system, let alone what to do when the backup system fails. Thus, even if the 
Pagano reference could be combined with the Satoh patent, which it cannot, the 
combination would not teach a source database that remains available during recovery of 
the recovered target database. 

The Satoh Patent And The Pagano References Cannot Be Combined 

Section 2143 of the M.P.E.P. states that to establish prima facie obviousness three 
requirements must be met: 

"To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation of success. Finally, 
the prior art reference (or references when combined) must teach or suggest all 
the claim limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in 
the prior art, and not based on applicants disclosure." 

First, there is no suggestion or motivation to combine the Satoh patent and Pagano 
reference to obtain a system that both recovers a target system and reconciles the target 
system with a source system such that stale replication transactions are purged and 
wherein the source system remains available during recovery and reconciliation of the 
target system. 

Rather, it appears that the Examiner has impermissibly used hindsight derived from 
the teachings in the present application, and not the teachings of the prior art, to reject the 
claims. In re Dembiczak . 175 F.3d 994, 999 (Fed. Cir. 1999) (holding the Board 
impermissibly used hindsight in determining obviousness); See also, M.P.E.P., Sect. 
2145, part X.A. In Dembiczak . the Federal Circuit reiterated that a determination of 
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obviousness cannot simply rely on the inventor's disclosure as a "blueprint" without 
evidence of a suggestion, teaching or motivation in the prior art. Dembiczak , 175 F.3d 
994, 999. Also, according to M.P.E.P. Section 706.02(j), "[t]he teaching and suggestion 
to make the claimed combination and the reasonable expectation for success must both be 
found in the prior art and not based on applicant's disclosure." 

Second, there must be a reasonable expectation of success. Because neither the Satoh 
patent nor the Pagano reference teach the existence of inconsistencies that occur when 
recovering a target database such as the existence of stale replication transactions in a 
replication system, there doesn't appear to be any expectation of success that the two 
systems when combined would address the such problems. 

Furthermore, because neither the Satoh patent nor the Pagano reference teach how to 
resolve replication inconsistencies by purging stale replication transactions, there doesn't 
appear to be any expectation of success that the two systems when combined would 
address the such problems. 

Third, neither the Satoh patent nor the Pagano reference teach all the claimed 
limitations. Thus, even when combined, the Satoh patent and the Pagano reference would 
not teach Applicant's claimed invention. 

Applicant therefore respectfully submits that Claim 1 is patentably distinguished over 
the cited references and Applicant respectfully requests allowance of Claim 1 . 

Claims 2-25 

The rejection of Claims 2-25 is improper for the reasons as set forth with respect to 
Claim 1 and because of the additional limitations recited therein. However, for the 
purposes of Applicant's appeal of the rejection under 35 U.S.C. § 103, Claims 2-25 stand 
or fall with Claim 1 . 
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Independent Claim 26 

The rejection of independent Claim 26 is improper for the reasons as set forth with 
respect to Claim 1. In addition, the cited references also do not teach the claimed 
placement indicators. 

The Cited References Do Not Teach the Use Of Two Placement Indicators 

Claim 26 is directed to a method of reconciling transactional information stored in a 
replication system with a recovered database. The claimed method refers to at least two 
types of placement indicators - 1) the placement indicator of a recovery flag and 2) the 
placement indictors of completed transactions. Claim 26 recites as follows: 

"parsing a log file of a recovered database to determine a placement 

indicator of a recovery flag;, . . 

reading the transaction data corresponding to changes made to a source 

database to determine placement indicators of completed transactions" 

The first type of placement indicator is a placement indicator for a recovery flag. The 
second type of placement indictor relates to placement indicators of transactions that have 
been completed in the source database. 

The Examiner, however, asserts that the cited references teach these two different 
types of placement indicators. Unfortunately, the Examiner provides very little basis for 
the rejection of Claim 26. Applicant notes, however, that with respect to dependent 
Claim 23, the Examiner states that the Pagano reference on pages 7-8 teaches a 
checkpoint. The Examiner asserts that this checkpoint is a recovery marker. 

The Pagano reference, however, specifically states that the checkpoint is in indicator 

of committed transactions, not a recovery marker: 

"The "checkpoint" is referred to as the place marker within the EDB.CHK 
file that indicates which transactions have been committed." See Pagano 
reference page 7, paragraph entitled "Checkpoint Files And The 
'Checkpoint'". 
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Thus, the checkpoint in the Pagano reference doesn't appear to be a recovery marker 
that identifies the point of recovery of a recovered target database. Rather, the checkpoint 
is used in the Pagano reference determines what transactions have been committed prior 
to failure of a database. The Examiner also doesn't provide any citations regarding 
whether the Satoh patent teaches a recovery marker. 

Neither the Pagano reference nor the Satoh patent teach two types of placement 
markers as set forth in Claim 26. Accordingly, even if the Pagano reference could be 
combined with the Satoh patent, which they cannot, the combination would not teach the 
claimed two types of placement markers. Therefore, Applicant respectfully requests 
allowance of Claim 26. 

Dependent Claims 27-33 

The rejection of dependent Claims 27-33 is improper for the reasons as set forth with 
respect to Claim 26 and because of the additional limitations recited therein. However, 
for the purposes of Applicant's appeal of the rejection under 35 U.S.C. § 103, Claims 28- 
33 stand or fall with Claim 26. 

Independent Claim 34 

The rejection of independent Claim 34 is improper for the reasons as set forth with 
respect to Claim 1 and because of the additional limitations recited therein. However, for 
the purposes of Applicant's appeal of the rejection under 35 U.S.C. § 103, Claim 34 
stands or falls with Claim 1 . 

In view of the foregoing arguments distinguishing Claims 1-19 and 21-34 over the art 
of record, Applicant respectfully requests that the rejection of these claims be reversed. 
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Please charge any additional fees, including any fees for additional extensions of 
time, or credit overpayment to Deposit Account No. 1 1-1410. 

Respectfully submitted, 

KNOBBE, MARTENS, OLSON & BEAR, LLP 



Dated: fa -?/- oS~ 



2015235 
102205 



By 




John R. King 
Registration No. 34,Y62 
Attorney of Record 
2040 Main Street, Fourteenth Floor 
Irvine, California 92614 
(949) 760-0404 
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VIII. CLAIMS APPENDIX 



1 . A device for performing replication between a source system and a target 
system, the device comprising: 

a source system having data files, and log files storing replication 
transactions corresponding to changes made to the data files; 

a recovered target system wherein the recovered target system comprises a 
rolled back copy of the data files in the source system and wherein the rolled back 
copy of the data files comprises data that is associated with at least one replication 
transaction stored in the log files; and 

a replication system performing replication of at least portions of the data 
files of the source system to the recovered target system by reading the log files 
and posting the changes from the log files to the recovered target system, the 
replication system comprising: 



transaction-level poster queues, each poster queue storing statements 
corresponding to a particular replication transaction from the source system, 
and 

a reconcile process which purges replication transactions from the 
poster queues when the replication transactions have already been applied 
to the recovered target system; and 

wherein the replication system performs the replication transactions 
by rolling forward at least some of the information rolled back during the 
recovery of the recovered target system such that the purged replication 
transactions in the poster queues are not applied while rolling forward such 
that the source database remains available during recovery of the recovered 
target database. 
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2. A replication system for replicating at least portions of the data contained 
in a source database to a target database, the replication system comprising: 

poster queues which store information corresponding to changes made to at 
least portions of a source system; 

at least one poster process which reads the information stored in the poster 
queues and generates commands interpretable by a target system and designed to 
change the target system to reflect the changes made to the at least portions of the 
source system; 

instantiation or recovery process of the target system that rolls back 
information previously applied to the target system such that the target system 
comprises at least a copy of some of the information stored in the poster queues; 
and 

a reconcile process which purges stale information stored in the poster 
queues, the stale information corresponding to changes made to the target system 
during the instantiation or recovery thereof; and wherein the poster queues roll 
forward at least some of the information rolled back during the recovery of the 
recovered target system such that the purged stale information is not applied while 
rolling forward and wherein the source system remains available during 
instantiation or recovery of the target database. 

3. The replication system of Claim 2, wherein the information comprises 
transactions. 

4. The replication system of Claim 2, wherein the at least one poster process 
reads a completion indicator from the poster queues, wherein the completion 
indicator corresponds to one or more finalized changes made to the source system. 

5. The replication system of Claim 4, wherein the completion indicator 
corresponds to a COMMIT statement. 
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6. The replication system of Claim 2, wherein the reconcile process employs 
placement indicators to determine which information stored in the poster queues is 
stale. 

7. The replication system of Claim 6, wherein one of the placement indicators 
corresponds to a recovery marker placed by the target system, wherein the recovery 
marker identifies how much of the information the target system already applied 
during recovery thereof. 

8. The replication system of Claim 6, wherein one of the placement 
indicators corresponds to a particular portion of the information. 

9. The replication system of Claim 6, wherein each placement indicator 
comprises a sequence number identifying a log file where a particular portion of the 
information originated. 

10. The replication system of Claim 6, wherein each placement indicator 
comprises a displacement number identifying the displacement within a log file 
where a particular portion of the information originated. 

1 1 . The replication system of Claim 2, further comprising a reader process 
which reads the information from the source system. 

12. The replication system of Claim 2, further comprising a reader queue 
which stores information read from the source system. 

13. The replication system of Claim 2 5 wherein the replication includes 
mirroring at least portions of the source system on at least one target system. 

14. The replication system of Claim 2, wherein the replication includes load 
balancing functions based on one of software and hardware configurations of the 
source and target systems. 

15. The replication system of Claim 2, wherein the replication provides 
broadcast functions. 
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16. The replication system of Claim 2, wherein the replication provides 
consolidation functions. 

17. A method of recovering or instantiating a target database during 
replication from a source database to the target database, the method comprising: 

creating a target database that has a copy of data from a source database; 

logging replication transactions in a replication system wherein the 
replication transactions are associated with changes made to the source database; 

applying the replication transactions to the target database to maintain in the 
target database a copy of the source database; 

identifying an unsynchronizing event associated with the target database; 

recovering the target database by rolling back information previously 
applied to the target database such that the recovered target database contains a 
copy of at least some of the changes represented by the replication transactions 
contained in the replication system; 

reconciling the recovered target database with the replication transactions 
contained in the replication system, thereby purging stale replication transactions 
from the replication system ; and 

restarting replication by rolling forward at least some of the information 
rolled back during the recovery of the target database such that the purged stale 
replication transactions are not applied during replication and wherein the source 
database remains available during recovering, reconciling and restarting. 

1 8. The method of Claim 17, further comprising restarting replication. 

19. The method of Claim 18, wherein the restarting of the replication 
includes restarting at least one poster process. 



20. (Cancelled). 
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21. The method of Claim 17, wherein the creation of the copy includes 
employing a hot backup mode of a database management system of the source 
database. 

22. The method of Claim 17, wherein the recovery of the copy includes 
employing a database management system associated with the copy. 

23. The method of Claim 17, wherein the recovery of the copy includes 
placing a recovery marker in the recovered copy, thereby identifying a recovery 
position therein. 

24. The method of Claim 23, wherein the placement of the recovery marker 
occurs substantially near the end of recovering the copy. 

25. The method of Claim 23, wherein the reconciling finds the recovery 
marker and the stale transactions of the information correspond to those transactions 
that were completed on the source system before the placement of the recovery 
marker. 

26. A method of reconciling transactional information stored in a replication 
system with a recovered database, the method comprising: 

parsing a log file of a recovered database to determine a placement indicator 
of a recovery flag; 

rolling back information previously applied to a recovered database, 
wherein the recovered database comprises at least some data that is also 
represented by transaction data that exists in the log file; 

reading the transaction data corresponding to changes made to a source 
database to determine placement indicators of completed transactions; 

purging the transactional data when the placement indicator corresponding 
to the completed transaction occurred before the placement indicator of the 
recovery flag; and 
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replicating the transactional data to the recovered database by rolling 
forward at least some of the information rolled back during the recovery of the 
recovered database such that the purged transaction data are not applied during 
replication such that the source database remains available while replicating the 
transactional data to the recovered database. 

27. The method of Claim 26, wherein the transaction data is read from the 
source database. 

28. The method of Claim 26, wherein the placement indicator of the 
completed transaction comprises a sequence number of a log file of the source 
database. 

29. The method of Claim 28, wherein the sequence number uniquely 
identifies the log file. 

30. The method of Claim 26, wherein the placement indicator of the recovery 
flag comprises a sequence number of a log file of the recovered database. 

31. The method of Claim 30, wherein the sequence number uniquely 
identifies the log file. 

32. The method of Claim 26, wherein the placement indicator comprises a 
displacement within a log file. 

33. The method of Claim 26, wherein the recovery flag is placed by a 
database management system of the recovered database. 

34. A device comprising: 

a source system having a source database management system (SDBMS) 
which governs the storage of data within the source system and creates a log file 
tracking changes made to the source system; 

a target system having a target database management system (TDBMS) 
which governs the storage of data within the target system and creates a log file 
tracking the changes made to the target system wherein the target database 
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management system is configured to recover the target system by rolling back 
portions of previously applied information; and 

a replication system having queues and communicating with the log file of 
the TDBMS and the log file of the SDBMS, thereby purging from the queues the 
replication transactions applied after the beginning, but before the completion, of 
the recovery of the target system, wherein the replication transactions correspond 
to the changes made to the source system wherein the replication system is 
configured to roll forward at least some of the information rolled back during the 
recovery of the target system such that the purged replication transactions are not 
applied during replication such that the source system remains available during 
recovery of the target database. 
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IX. EVIDENCE APPENDIX 

None. 

X. RELATED PROCEEDINGS APPENDIX 

None. 
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